I haven't looked too closely at this yet, but I'll go ahead and give some of my general thoughts.

• If this was accepted, it specifically hard codes one specific case. It doesn't handle escapes if you were to escape an `. It doesn't handle other user plugins if they are inserted before references or even custom inline code replacements (which I have one).

  Now we could just say this only supports the built-in code module, and 3rd party plugins would simply have to derive their own reference replacement as well. This would be annoying, but a possible path. But then you could never have a unified way to account for any all plugins before reference.

• More generally, Python Markdown, being an old-school parser, generally implements Markdown that mimics PHP Markdown, which also doesn't seem to support this. At least as far as I can see via version 1.9.1 on Babelmark. If this is something we cannot adequately generalize for all extensions that come before the refrence extension, is it worth adding all the complexity?

There are probably ways to do this generally, but it would had a bit of code complexity to maintain. Maybe, assuming the reference extension is registered:

• on reset, it scans for any extensions that come before it in priority, adds them to its own inline processor.
• IDs are converted to using these inline processors.
• Placeholders are expanded, normalized, and compared against IDs.

Now I haven't really ever prototyped this, and I'm not sure of all the pitfalls that could be involved.

To be honest, this would work best if Python Markdown processed the content into an AST first. This is how most modern parsers achieve what you are after. All context is available before the rendering step. Python Markdown, on the other hand, is parsing and rendering along the way, losing context at times in future steps. A big rewrite of Python Markdown is likely never going to happen.

Fair enough, was hoping for some consistency with normal links. Will just pre-process references with backticks with find & replace approach.

There was a PR to fix this in in php-markdown but I cant seem to find it any more - although the 1.x branch is not getting updates. I believe it is fixed in the 2.x branch, so I assume this lib will stick with the 1.x implementation.

Again, these are just my general opinions. @waylan has the final say.

I never use anything but normal, simple identifiers for references, even when using parsers that could parse code blocks as references. I'm also not against having support for code blocks as references. My personal preference would be that it was general enough to support most anything, rather than hard-coding a solution. @waylan may be fine with the direction.

I think it is likely possible to pull off something general enough, and that works well enough to be suitable. I question how much it is worth the effort, but I'm not against it per se. I realize that there may always be some corner cases where this doesn't work, but if it were "good enough", and "general enough", I think it would be fine.

There was a PR to fix this in in php-markdown but I cant seem to find it any more - although the 1.x branch is not getting updates. I believe it is fixed in the 2.x branch, so I assume this lib will stick with the 1.x implementation.

I don't know, its architecture is different and their goals of what they want in the future may be different than ours. That's at least where Python Markdown started, using PHP Markdown as the reference.